1. Technical Field
The present disclosure relates to methods for allocating radio resources to sidelink logical channels when performing a logical channel prioritization procedure. The present disclosure is also providing the user equipment for participating in the methods described herein.
2. Description of the Related Art
Long Term Evolution (LTE)
The specification of Long-Term Evolution (LTE) has been finalized as Release 8 (LTE Rel. 8) as a system following the 3rd Generation Partnership Project (3GPP) Universal Mobile Terrestrial Network. The LTE system represents efficient packet-based radio access that provides full IP-based functionalities with low latency and low cost. In LTE, scalable multiple transmission bandwidths are specified such as 1.4, 3.0, 5.0, 10.0, 15.0, and 20.0 MHz, in order to achieve flexible system deployment using a given spectrum. In the downlink, Orthogonal Frequency Division Multiplexing (OFDM) based radio access was adopted because of its inherent immunity to multipath interference (MPI) due to a low symbol rate, the use of a cyclic prefix (CP) and its affinity to different transmission bandwidth arrangements. Single-carrier frequency division multiple access (SC-FDMA) based radio access was adopted in the uplink, since provisioning of wide area coverage was prioritized over improvement in the peak data rate considering the restricted transmit power of the user equipment (UE). Many key packet radio access techniques are employed including multiple-input multiple-output (MIMO) channel transmission techniques and a highly efficient control signaling structure is achieved in LTE Rel. 8/9.
LTE Architecture
The overall architecture is shown in FIG. 1 and a more detailed representation of the E-UTRAN architecture is given in FIG. 2. The E-UTRAN consists of an eNodeB, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the user equipment (UE). The eNodeB (eNB) hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC) and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated uplink Quality of Service (QoS), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of downlink/uplink user plane packet headers. The eNodeBs are interconnected with each other by means of the X2 interface.
The eNodeBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (SGW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNodeBs. The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNodeB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state user equipments, the SGW terminates the downlink data path and triggers paging when downlink data arrives for the user equipment. It manages and stores user equipment contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode user equipment tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a user equipment at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to user equipments. It checks the authorization of the user equipment to camp on the service provider's Public Land Mobile Network (PLMN) and enforces user equipment roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming user equipments.
Component Carrier Structure in LTE
The downlink component carrier of a 3GPP LTE system is subdivided in the time-frequency domain in so-called subframes. In 3GPP LTE each subframe is divided into two downlink slots, wherein the first downlink slot includes the control channel region (PDCCH region) within the first OFDM symbols. Each subframe consists of a give number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Release 8)), wherein each OFDM symbol spans over the entire bandwidth of the component carrier. The OFDM symbols thus each consists of a number of modulation symbols transmitted on respective subcarriers as also shown in FIG. 3.
Assuming a multi-carrier communication system, e.g. employing OFDM, as for example used in 3GPP Long Term Evolution (LTE), the smallest unit of resources that can be assigned by the scheduler is one “resource block”. A physical resource block (PRB) is defined as consecutive OFDM symbols in the time domain (e.g. 7 OFDM symbols) and consecutive subcarriers in the frequency domain as exemplified in FIG. 3 (e.g. 12 subcarriers for a component carrier). In 3GPP LTE (Release 8), a physical resource block thus consists of resource elements, corresponding to one slot in the time domain and 180 kHz in the frequency domain (for further details on the downlink resource grid, see for example 3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)”, Section 6.2, available at www.3gpp.org, and incorporated herein by reference).
One subframe consists of two slots, so that there are 14 OFDM symbols in a subframe when a so-called “normal” CP (cyclic prefix) is used, and 12 OFDM symbols in a subframe when a so-called “extended” CP is used. For sake of terminology, in the following the time-frequency resources equivalent to the same consecutive subcarriers spanning a full subframe is called a “resource block pair”, or equivalent “RB pair” or “PRB pair”.
The term “component carrier” refers to a combination of several resource blocks in the frequency domain. In future releases of LTE, the term “component carrier” is no longer used; instead, the terminology is changed to “cell”, which refers to a combination of downlink and optionally uplink resources. The linking between the carrier frequency of the downlink resources and the carrier frequency of the uplink resources is indicated in the system information transmitted on the downlink resources.
Similar assumptions for the component carrier structure apply to later releases too.
Carrier Aggregation in LTE-A for Support of Wider Bandwidth
In carrier aggregation available in LTE from Release 10 on, two or more component carriers are aggregated in order to support wider transmission bandwidths up to 100 MHz. Several cells in the LTE system are aggregated into one wider channel in the LTE-Advanced system which is wide enough for 100 MHz even though these cells in LTE may be in different frequency bands.
All component carriers can be configured to be LTE Rel. 8/9 compatible, at least when the bandwidth of a component carrier do not exceed the supported bandwidth of a LTE Rel. 8/9 cell. Not all component carriers aggregated by a user equipment may necessarily be Rel. 8/9 compatible. Existing mechanism (e.g. barring) may be used to avoid Rel-8/9 user equipments to camp on a component carrier.
A user equipment may simultaneously receive or transmit one or multiple component carriers (corresponding to multiple serving cells) depending on its capabilities. A LTE-A Rel. 10 user equipment with reception and/or transmission capabilities for carrier aggregation can simultaneously receive and/or transmit on multiple serving cells, whereas an LTE Rel. 8/9 user equipment can receive and transmit on a single serving cell only, provided that the structure of the component carrier follows the Rel. 8/9 specifications.
Carrier aggregation is supported for both contiguous and non-contiguous component carriers with each component carrier limited to a maximum of 110 Resource Blocks in the frequency domain using the 3GPP LTE (Release 8/9) numerology. It is possible to configure a 3GPP LTE-A (Release 10) compatible user equipment to aggregate a different number of component carriers originating from the same eNodeB (base station) and of possibly different bandwidths in the uplink and the downlink. The number of downlink component carriers that can be configured depends on the downlink aggregation capability of the UE. Conversely, the number of uplink component carriers that can be configured depends on the uplink aggregation capability of the UE. It may currently not be possible to configure a mobile terminal with more uplink component carriers than downlink component carriers.
The spacing between center frequencies of contiguously aggregated component carriers shall be a multiple of 300 kHz. This is in order to be compatible with the 100 kHz frequency raster of 3GPP LTE (Release 8/9) and at the same time preserve orthogonality of the subcarriers with 15 kHz spacing. Depending on the aggregation scenario, the n*300 kHz spacing can be facilitated by insertion of a low number of unused subcarriers between contiguous component carriers.
The nature of the aggregation of multiple carriers is only exposed up to the MAC layer. For both uplink and downlink there is one HARQ entity required in MAC for each aggregated component carrier. There is (in the absence of SU-MIMO for uplink) at most one transport block per component carrier. A transport block and its potential HARQ retransmissions need to be mapped on the same component carrier.
LTE Layer 2—User Plane and Control Plane Protocol Stack
The LTE layer 2 user-plane/control-plane protocol stack includes three sublayers as shown in FIG. 4, PDCP, RLC and MAC. At the transmitting side, each layer receives a Service Data Unit, SDU, from a higher layer for which the layer provides a service and outputs a PDU to the layer below. The RLC layer receives packets from the PDCP layer. These packets are called PDCP PDUs from a PDCP point of view and represent RLC SDUs from an RLC point of view. The RLC layer creates packets which are provided to the layer below, i.e. the MAC layer. The packets provided by RLC to the MAC layer are RLC PDUs from an RLC point of view and MAC SDUs from a MAC point of view.
At the receiving side, the process is reversed, with each layer passing SDUs up to the layer above, where they are received as PDUs.
While the physical layer essentially provides a bitpipe, protected by turbo-coding and a cyclic redundancy check (CRC), the link-layer protocols enhance the service to upper layers by increased reliability, security and integrity. In addition, the link layer is responsible for the multi-user medium access and scheduling. One of the main challenges for the LTE link-layer design is to provide the required reliability levels and delays for Internet Protocol (IP) data flows with their wide range of different services and data rates. In particular, the protocol over-head must scale. For example, it is widely assumed that voice over IP (VoIP) flows can tolerate delays on the order of 100 ms and packet losses of up to 1 percent. On the other hand, it is well-known that TCP file downloads perform better over links with low bandwidth-delay products. Consequently, downloads at very high data rates (e.g., 100 Mb/s) require even lower delays and, in addition, are more sensitive to IP packet losses than VoIP traffic.
Overall, this is achieved by the three sublayers of the LTE link layer that are partly intertwined.
The Packet Data Convergence Protocol (PDCP) sublayer is responsible mainly for IP header compression and ciphering. In addition, it supports lossless mobility in case of inter-eNB handovers and provides integrity protection to higher layer-control protocols.
The radio link control (RLC) sublayer includes mainly ARQ functionality and supports data segmentation and concatenation. The latter two minimize the protocol overhead independent of the data rate.
Finally, the medium access control (MAC) sublayer provides HARQ and is responsible for the functionality that is required for medium access, such as scheduling operation and random access. FIG. 5 exemplary depicts the data flow of an IP packet through the link-layer protocols down to the physical layer. The figure shows that each protocol sublayer adds its own protocol header to the data units.
Uplink Access scheme for LTE
For uplink transmission, power-efficient user-terminal transmission is necessary to maximize coverage. Single-carrier transmission combined with FDMA with dynamic bandwidth allocation has been chosen as the evolved UTRA uplink transmission scheme. During each time interval, Node B assigns users a unique time/frequency resource for transmitting user data, thereby ensuring intra-cell orthogonality. An orthogonal access in the uplink promises increased spectral efficiency by eliminating intra-cell interference. Interference due to multipath propagation is handled at the base station (Node B), aided by insertion of a cyclic prefix in the transmitted signal.
The basic physical resource used for data transmission consists of a frequency resource of size BWgrant during one time interval, e.g. a sub-frame of 0.5 ms, onto which coded information bits are mapped. It should be noted that a sub-frame, also referred to as transmission time interval (TTI), is the smallest time interval for user data transmission. It is however possible to assign a frequency resource BWgrant over a longer time period than one TTI to a user by concatenation of sub-frames.
UL Scheduling Scheme for LTE
The uplink scheme allows for both scheduled access, i.e. controlled by eNB, and contention-based access.
In case of scheduled access, the UE is allocated a certain frequency resource for a certain time (i.e. a time/frequency resource) for uplink data transmission. However, some time/frequency resources can be allocated for contention-based access. Within these time/frequency resources, UEs can transmit without first being scheduled. One scenario where UE is making a contention-based access is for example the random access, i.e. when UE is performing initial access to a cell or for requesting uplink resources.
For the scheduled access the Node B scheduler assigns a user a unique frequency/time resource for uplink data transmission. More specifically the scheduler determines which UE(s) is (are) allowed to transmit, which physical channel resources (frequency), and the transport format (Modulation Coding Scheme (MCS)) to be used by the mobile terminal for transmission.
The allocation information is signaled to the UE via a scheduling grant, sent on the L1/L2 control channel (called “uplink grant channel” in the following). A scheduling grant message contains information which part of the frequency band the UE is allowed to use, the validity period of the grant, and the transport format the UE has to use for the upcoming uplink transmission. The shortest validity period is one sub-frame. Additional information may also be included in the grant message for the UE, depending on the selected scheme. The UE then distributes the allocated resources among its radio bearers according to some rules. The eNB decides the transport format based on some information, e.g. reported scheduling information and QoS info, and the UE has to follow the selected transport format. Since the scheduling of radio resources is the most important function in a shared-channel access network for determining Quality of Service, there are a number of requirements that should be fulfilled by the UL scheduling scheme for LTE in order to allow for an efficient QoS management.                Starvation of low priority services should be avoided. Starvation means that the data from the low-priority logical channels cannot be transmitted because the data from high-priority logical channels take up all the MAC PDU space;        Clear QoS differentiation for radio bearers/services should be supported by the scheduling scheme;        The UL reporting should allow fine granular buffer reports (e.g. per radio bearer or per radio bearer group) in order to allow the eNB scheduler to identify for which Radio Bearer/service data is to be sent;        It should be possible to make clear QoS differentiation between services of different users; and        It should be possible to provide a minimum bit rate per radio bearer.        
As can be seen from the above list, one essential aspect of the LTE scheduling scheme is to provide mechanisms with which the operator can control the partitioning of its aggregated cell capacity between the radio bearers of the different QoS classes.
Logical Channel Prioritization, LCP, Procedure
For the uplink the process by which a UE creates a MAC PDU to transmit using the allocated radio resources is fully standardized; this is designed to ensure that the UE satisfies the QoS of each configured radio bearer in a way which is optimal and consistent between different UE implementations. Based on the uplink transmission resource grant message signaled on the PDCCH, the UE has to decide on the amount of data for each logical channel to be included in the new MAC and, if necessary, also to allocate space for a MAC Control Element.
In constructing a MAC PDU with data from multiple logical channels, the simplest and most intuitive method is the absolute priority-based method, where the MAC PDU space is allocated to logical channels in decreasing order of logical channel priority. This is, data from the highest priority logical channel are served first in the MAC PDU, followed by data from the next highest priority logical channel, continuing until the MAC PDU space runs out. Although the absolute priority-based method is quite simple in terms of UE implementation, it sometimes leads to starvation of data from low-priority logical channels.
In LTE, a Prioritized Bit Rate (PBR) is defined for each logical channel, in order to transmit data in order of importance but also to avoid starvation of data with lower priority. The PBR is the minimum data rate guaranteed for the logical channel. Even if the logical channel has low priority, at least a small amount of MAC PDU space is allocated to guarantee the PBR. Thus, the starvation problem can be avoided by using the PBR.
Constructing a MAC PDU with PBR consists of two rounds. In the first round, each logical channel is served in decreasing order of logical channel priority, but the amount of data from each logical channel included in the MAC PDU is initially limited to the amount corresponding to the configured PBR value of the logical channel. After all logical channels have been served up to their PBR values, if there is room left in the MAC PDU, the second round is performed. In the second round, each logical channel is served again in decreasing order of priority. The major difference for the second round compared to the first round is that each logical channel of lower priority can be allocated with MAC PDU space only if all logical channels of higher priority have no more data to transmit.
A MAC PDU may include not only the MAC SDUs from each configured logical channel but also a MAC CE (Control Elements). Except for a Padding BSR (Buffer Status Report), the MAC CE has a higher priority than a MAC SDU from the logical channels because it controls the operation of the MAC layer. Thus, when a MAC PDU is composed, the MAC CE, if it exists, is the first to be included, and the remaining space is used for MAC SDUs from the logical channels. Then, if additional space is left and it is large enough to include a BSR, a Padding BSR is triggered and included in the MAC PDU.
The Logical Channel Prioritization for uplink is standardized e.g. in 3GPP TS 36.321, “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification”, (latest version v12.4.0) in Section 5.4.3.1, available at www.3gpp.org, and incorporated herein.
The Logical Channel Prioritization (LCP) procedure is applied when a new transmission of a transport block is performed (i.e. not at retransmissions of the same data).
RRC controls the scheduling of uplink data by signaling for each logical channel:                priority where an increasing priority value indicates a lower priority level;        prioritisedBitRate which sets the Prioritized Bit Rate (PBR); and        bucketSizeDuration which sets the Bucket Size Duration (BSD).        
The UE shall maintain a variable Bj for each logical channel j. Bj shall be initialized to zero when the related logical channel is established, and incremented by the product PBR×TTI duration for each TTI, where PBR is Prioritized Bit Rate of logical channel j. However, the value of Bj can never exceed the bucket size, and if the value of Bj is larger than the bucket size of logical channel j, it shall be set to the bucket size. The bucket size of a logical channel is equal to PBR*BSD, where PBR and BSD are configured by upper layers.
The UE (MAC entity) shall perform the following Logical Channel Prioritization procedure when a new transmission is performed:                The UE (MAC entity) shall allocate resources to the logical channels in the following steps:                    Step 1: All the logical channels with Bj>0 are allocated resources in a decreasing priority order. If the PBR of a radio bearer is set to “infinity”, the UE shall allocate resources for all the data that is available for transmission on the radio bearer before meeting the PBR of the lower priority radio bearer(s);            Step 2: the UE (MAC entity) shall decrement Bj by the total size of MAC SDUs served to logical channel j in Step 1,NOTE: The value of Bj can be negative; and            Step 3: if any resources remain, all the logical channels are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.                        The UE (MAC entity) shall also follow the rules below during the scheduling procedures above:                    The UE (MAC entity) should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources;            if the UE (MAC entity) segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant as much as possible;            the UE (MAC entity) should maximize the transmission of data; and            if the UE (MAC entity) is given an UL grant size that is equal to or larger than 4 bytes while having data available for transmission, the UE (MAC entity) shall not transmit only padding BSR and/or padding (unless the UL grant size is less than 7 bytes and an AMD PDU segment needs to be transmitted).                        
The UE shall not transmit data for a logical channel corresponding to a radio bearer that is suspended (the conditions for when a radio bearer is considered suspended are defined in 3GPP TS 36.331, 12.5.0, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification”, available at www.3gpp.org).
For the Logical Channel Prioritization procedure, the UE shall take into account the following relative priority in decreasing order:                MAC control element for C-RNTI or data from UL-CCCH;        MAC control element for BSR, with exception of BSR included for padding;        MAC control element for PHR or Extended PHR, or Dual Connectivity PHR;        data from any Logical Channel, except data from UL-CCCH; and        MAC control element for BSR included for padding.        
When the UE is requested to transmit multiple MAC PDUs in one TTI, steps 1 to 3 and the associated rules may be applied either to each grant independently or to the sum of the capacities of the grants. Also the order in which the grants are processed is left up to UE implementation. It is up to the UE implementation to decide in which MAC PDU a MAC control element is included when the UE is requested to transmit multiple MAC PDUs in one TTI.
Buffer Status Reporting
The usual mode of scheduling is dynamic scheduling, by means of downlink assignment messages for the allocation of downlink transmission resources and uplink grant messages for the allocation of uplink transmission resources; these are usually valid for specific single subframes. They are transmitted on the PDCCH using the C-RNTI of the UE. Dynamic scheduling is efficient for services types in which the traffic is bursty and dynamic in rate, such as TCP.
In addition to the dynamic scheduling, a persistent scheduling is defined, which enables radio resources to be semi-statically configured and allocated to a UE for a longer time period than one subframe, thus avoiding the need for specific downlink assignment messages or uplink grant messages over the PDCCH for each subframe. Persistent scheduling is useful for services such as VoIP for which the data packets are small, periodic and semi-static in size. Thus, the overhead of the PDCCH is significantly reduced compared to the case of dynamic scheduling.
Buffer status reports (BSR) from the UE to the eNodeB are used to assist the eNodeB in allocating uplink resources, i.e. uplink scheduling. For the downlink case, the eNB scheduler is obviously aware of the amount of data to be delivered to each UE; however, for the uplink direction, since scheduling decisions are done at the eNB and the buffer for the data is in the UE, BSRs have to be sent from the UE to the eNB in order to indicate the amount of data that needs to be transmitted over the UL-SCH.
Buffer Status Report MAC control elements for LTE consist of either: a long BSR (with four buffer size fields corresponding to LCG IDs #0-3) or a short BSR (with one LCG ID field and one corresponding buffer size field). The buffer size field indicates the total amount of data available across all logical channels of a logical channel group, and is indicated in number of bytes encoded as an index of different buffer size levels (see also 3GPP TS 36.321, “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification” v 12.4.0 Section 6.1.3.1, available at www.3gpp.org, and incorporated herewith by reference).
Which one of either the short or the long BSR is transmitted by the UE depends on the available transmission resources in a transport block, on how many groups of logical channels have non-empty buffers and on whether a specific event is triggered at the UE. The long BSR reports the amount of data for four logical channel groups, whereas the short BSR indicates the amount of data buffered for only the highest logical channel group.
The reason for introducing the logical channel group concept is that even though the UE may have more than four logical channels configured, reporting the buffer status for each individual logical channel would cause too much signaling overhead. Therefore, the eNB assigns each logical channel to a logical channel group; preferably, logical channels with same/similar QoS requirements should be allocated within the same logical channel group.
In order to be robust against transmission failures, there is a BSR retransmission mechanism defined for LTE; the retransmission BSR timer is started or restarted whenever an uplink grant is restarted; if no uplink grant is received before the retransmission BSR timer expires, another BSR is triggered by the UE.
A BSR is triggered for events, such as:                Whenever data arrives for a logical channel, which has a higher priority than the logical channels whose buffer are non-empty (i.e. whose buffer previously contained data);        Whenever data becomes available for any logical channel, when there was previously no data available for transmission (i.e. all buffers previously empty);        Whenever the retransmission BSR time expires;        Whenever periodic BSR reporting is due, i.e. periodic BSR timer expires; and        Whenever there is a spare space in a transport block which can accommodate a BSR.        
More detailed information with regard to BSR and in particular the triggering of same is explained in the specification 3GPP TS 36.321 v12.4.0 in Section 5.4.5, available at www.3gpp.org, and incorporated herewith by reference.
If the UE has no uplink resources allocated for including a BSR in the transport block when a BSR is triggered, the UE sends a scheduling request (SR) to the eNodeB so as to be allocated with uplink resources to transmit the BSR. Either a single-bit scheduling request is sent over the PUCCH (dedicated scheduling request, D-SR), or the random access procedure (RACH) is performed to request an allocation of an uplink radio resource for sending a BSR. LTE Device to Device (D2D) Proximity Services (ProSe)
Proximity-based applications may be used in areas including services related to commercial services and Public Safety that would be of interest to operators and users. Device-to-Device (D2D) communication is a technology component for LTE-Re1.12 which enables direct communication between user terminals without the traffic passing any base station. The Device-to-Device (D2D) communication technology allows D2D as an underlay to the cellular network to increase the spectral efficiency. For example, if the cellular network is LTE, all data carrying physical channels use SC-FDMA for D2D signaling.
D2D Communication in LTE
The D2D communication in LTE is focusing on two areas: Discovery and Communication.
ProSe (Proximity based Services) Direct Discovery is defined as the procedure used by the ProSe-enabled UE to discover other ProSe-enabled UE(s) in its proximity using E-UTRA direct radio signals via the PC5 interface. FIG. 6 schematically illustrates a PC5 interface for device-to-device direct discovery between UE A and UE B. It also schematically illustrates a Radio Protocol Stack (AS) for ProSe Direct Discovery including the physical layer, the L2 radio protocol (which can be MAC) and a ProSe protocol of a “higher layer”.
In D2D communication UEs transmit data signals to each other over a direct link using the cellular resources instead of through the base station (BS). D2D users communicate directly while remaining controlled under the BS, i.e. at least when being in coverage of an eNB. Therefore, D2D can improve system performances by reusing cellular resources.
It is assumed that D2D operates in the uplink LTE spectrum (in the case of FDD) or uplink sub-frames of the cell giving coverage (in case of TDD, except when out of coverage). Furthermore, D2D transmission/reception does not use full duplex on a given carrier. From individual UE perspective, on a given carrier D2D signal reception and LTE uplink transmission do not use full duplex, i.e. no simultaneous D2D signal reception and LTE UL transmission is possible.
In D2D communication when one particular UE1 has a role of transmission (transmitting user equipment or transmitting terminal), UE1 sends data, and another UE2 (receiving user equipment) receives it. UE1 and UE2 can change their transmission and reception role. The transmission from UE1 can be received by one or more UEs like UE2.
With respect to the User plane protocols, in the following part of the agreement from D2D communication perspective is given (see also 3GPP TR 36.843, current version 12.0.1, “Study on LTE device to device proximity services; Radio aspects”, Section 9.2.2, available at www.3gpp.org incorporated herein by reference):
PDCP:                1:M (one device transmits to M devices, M being an integer) D2D broadcast communication data (i.e. IP packets) should be handled as the normal user-plane data; and        Header-compression/decompression in PDCP is applicable for 1:M D2D broadcast communication,                    U-Mode is used for header compression in PDCP for D2D broadcast operation for public safety.                        
RLC:                RLC UM is used for 1:M D2D broadcast communication;        Segmentation and Re-assembly is supported on L2 by RLC UM;        A receiving UE needs to maintain at least one RLC UM entity per transmitting peer UE;        An RLC UM receiver entity does not need to be configured prior to reception of the first RLC UM data unit; and        So far no need has been identified for RLC AM or RLC TM for D2D communication for user plane data transmission.        
MAC:                No HARQ feedback is assumed for 1:M D2D broadcast communication;        The receiving UE needs to know a source ID in order to identify the receiver RLC UM entity;        The MAC header includes a L2 target ID which allows filtering out packets at MAC layer;        The L2 target ID may be a broadcast, group cast or unicast address:                    L2 Groupcast/Unicast: A L2 target ID carried in the MAC header would allow discarding a received RLC UM PDU even before delivering it to the RLC receiver entity; and            L2 Broadcast: A receiving UE would process all received RLC PDUs from all transmitters and aim to re-assemble and deliver IP packets to upper layers;                        MAC sub header contains LCIDs (to differentiate multiple logical channels); and        At least Multiplexing/de-multiplexing, priority handling and padding are useful for D2D.ProSe Direct Communication Related Identities        
ProSe Direct Communication Related identities 3GPP TS 36.300, “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2”, current version 12.4.0, available at www.3gpp.org, defines in Section 8.3 the following identities to use for ProSe Direct Communication:                SL-RNTI: Unique identification used for ProSe Direct Communication Scheduling;        Source Layer-2 ID: Identifies the sender of the data in sidelink ProSe Direct Communication. The Source Layer-2 ID is 24 bits long and is used together with ProSe Layer-2 Destination ID and LCID for identification of the RLC UM entity and PDCP entity in the receiver; and        Destination Layer-2 ID: Identifies the target of the data in sidelink ProSe Direct Communication. The Destination Layer-2 ID is 24 bits long and is split in the MAC layer into two bit strings:                    One bit string is the LSB part (8 bits) of Destination Layer-2 ID and forwarded to physical layer as Sidelink Control Layer-1 ID. This identifies the target of the intended data in Sidelink Control and is used for filtering of packets at the physical layer; and            Second bit string is the MSB part (16 bits) of the Destination Layer-2 ID and is carried within the MAC header. This is used for filtering of packets at the MAC layer.                        
No Access Stratum signaling is required for group formation and to configure Source Layer-2 ID, Destination Layer-2 ID and Sidelink Control L1 ID in the UE. These identities are either provided by higher layer or derived from identities provided by higher layer. In case of groupcast and broadcast, the ProSe UE ID provided by higher layer is used directly as the Source Layer-2 ID, and the ProSe Layer-2 Group ID provided by higher layer is used directly as the Destination Layer-2 ID in the MAC layer.
Radio Resource Allocation for Proximity Services
From the perspective of a transmitting UE, a Proximity-Services-enabled UE (ProSe-enabled UE) can operate in two modes for resource allocation:
Mode 1 refers to the eNB-scheduled resource allocation, where the UE requests transmission resources from the eNB (or Release-10 relay node), and the eNodeB (or Release-10 relay node) in turn schedules the exact resources used by a UE to transmit direct data and direct control information (e.g. Scheduling Assignment). The UE needs to be RRC_CONNECTED in order to transmit data. In particular, the UE sends a scheduling request (D-SR or Random Access) to the eNB followed by a buffer status report (BSR) in the usual manner (see also following chapter “Transmission procedure for D2D communication”). Based on the BSR, the eNB can determine that the UE has data for a ProSe Direct Communication transmission, and can estimate the resources needed for transmission.
On the other hand, Mode 2 refers to the UE-autonomous resource selection, where a UE on its own selects resources (time and frequency) from resource pool(s) to transmit direct data and sidelink control information (i.e. SA). One resource pool is defined e.g. by the content of SIB18, namely by the field commTxPoolNormalCommon, this particular resource pool being broadcast in the cell, and then commonly available for all UEs in the cell still in RRC_Idle state. Effectively, the eNB may define up to four different instances of said pool, respectively four resource pools for the transmission of SA messages and direct data. However, a UE shall always use the first resource pool defined in the list, even if it was configured with multiple resource pools for Release 12 LTE. Later versions of the standard may handle differently.
As an alternative, another resource pool can be defined by the eNB and signaled in SIB18, namely by using the field commTxPoolExceptional, which can be used by the UEs in exceptional cases.
What resource allocation mode a UE is going to use is configurable by the eNB. Furthermore, what resource allocation mode a UE is going to use for D2D data communication may also depend on the RRC state, i.e. RRC_IDLE or RRC— CONNECTED, and the coverage state of the UE, i.e. in-coverage, out-of-coverage. A UE is considered in-coverage if it has a serving cell (i.e. the UE is RRC_CONNECTED or is camping on a cell in RRC_IDLE).                The following rules with respect to the resource allocation mode apply for the UE:        If the UE is out-of-coverage, it can only use Mode 2;        If the UE is in-coverage, it may use Mode 1 if the eNB configures it accordingly; and        If the UE is in-coverage, it may use Mode 2 if the eNB configures it accordingly.        
When there are no exceptional conditions, UE may change from Mode 1 to Mode 2 or vice-versa only if it is configured by eNB to do so. If the UE is in-coverage, it shall use only the mode indicated by eNB configuration unless one of the exceptional cases occurs;                The UE considers itself to be in exceptional conditions e.g. while T311 or T301 is running; and        When an exceptional case occurs the UE is allowed to use Mode 2 temporarily even though it was configured to use Mode 1.While being in the coverage area of an E-UTRA cell, the UE shall perform ProSe Direct Communication Transmission on the UL carrier only on the resources assigned by that cell, even if resources of that carrier have been pre-configured e.g. in UICC (Universal Integrated Circuit Card).        
For UEs in RRC_IDLE the eNB may select one of the following options:                The eNB may provide a Mode 2 transmission resource pool in SIB. UEs that are authorized for ProSe Direct Communication use these resources for ProSe Direct Communication in RRC _IDLE; and        The eNB may indicate in SIB that it supports D2D but does not provide resources for ProSe Direct Communication. UEs need to enter RRC_CONNECTED to perform ProSe Direct Communication transmission.        
For UEs in RRC_CONNECTED:—A UE in RRC_CONNECTED that is authorized to perform ProSe Direct Communication transmission, indicates to the eNB that it wants to perform ProSe Direct Communication transmissions when it needs to perform ProSe Direct Communication transmission:                The eNB validates whether the UE in RRC_CONNECTED is authorized for ProSe Direct Communication transmission using the UE context received from MME; and        The eNB may configure a UE in RRC_CONNECTED by dedicated signaling with a Mode-2 resource allocation transmission resource pool that may be used without constraints while the UE is RRC_CONNECTED. Alternatively, the eNB may configure a UE in RRC_CONNECTED by dedicated signaling with a Mode 2 resource allocation transmission resource pool which the UE is allowed to use only in exceptional cases and rely on Mode 1 otherwise.        
The resource pool for Scheduling Assignment when the UE is out of coverage can be configured as below:                The resource pool used for reception is pre-configured; and        The resource pool used for transmission is pre-configured.The resource pool for Scheduling Assignment when the UE is in coverage can be configured as below:        The resource pool used for reception is configured by the eNB via RRC, in dedicated or broadcast signaling;        The resource pool used for transmission is configured by the eNB via RRC if Mode 2 resource allocation is used;        The SA resource pool used for transmission is not known to the UE if Mode 1 resource allocation is used; and        The eNB schedules the specific resource(s) to use for Scheduling Assignment transmission if Mode 1 resource allocation is used. The specific resource assigned by the eNB is within the resource pool for reception of Scheduling Assignment that is provided to the UE.        
FIG. 7 illustrates the use of transmission/reception resources for overlay (LTE) and underlay (D2D) system.
Basically, the eNodeB controls whether UE may apply the Mode 1 or Mode 2 transmission. Once the UE knows its resources where it can transmit (or receive) D2D communication, it uses the corresponding resources only for the corresponding transmission/reception. For example, in FIG. 7, the D2D subframes will only be used to receive or transmit the D2D signals. Since the UE as a D2D device would operate in Half Duplex mode, it can either receive or transmit the D2D signals at any point of time. Similarly, the other subframes illustrated in FIG. 7 can be used for LTE (overlay) transmissions and/or reception.
Transmission Procedure for D2D Communication
The D2D data transmission procedure differs depending on the resource allocation mode. As described above for Mode 1, the eNB explicitly schedules the resources for the Scheduling Assignment and the D2D data communication after a corresponding request from the UE. Particularly, the UE may be informed by the eNB that D2D communication is generally allowed, but that no Mode 2 resources (i.e. resource pool) are provided; this may be done e.g. with the exchange of the D2D communication Interest Indication by the UE and the corresponding response, D2D Communication Response, where the corresponding exemplary ProseCommConfig information element mentioned above would not include the commTxPoolNormalCommon, meaning that a UE that wants to start direct communication involving transmissions has to request E-UTRAN to assign resources for each individual transmission. Thus, in such a case, the UE has to request the resources for each individual transmission, and in the following the different steps of the request/grant procedure are exemplarily listed for this Mode 1 resource allocation:                Step 1: UE sends SR (Scheduling Request) to eNB via PUCCH;        Step 2: eNB grants UL resource (for UE to send BSR) via PDCCH, scrambled by C-RNTI;        Step 3: UE sends D2D BSR indicating the buffer status via PUSCH;        Step 4: eNB grants D2D resource (for UE to send data) via PDCCH, scrambled by D2D-RNTI; and        Step 5: D2D Tx UE transmits SA/D2D data according to grant received in step 4.        
A Scheduling Assignment (SA) is a compact (low-payload) message containing control information, e.g. pointer(s) to time-frequency resources for the corresponding D2D data transmissions. The content of the SA is basically in accordance with the grant received in Step 4 above. The exact details of the D2D grant and SA content are not fixed yet but as a working assumption for the SA content the following agreements were achieved:                Frequency resource is indicated by Rel-8 UL Type 0 resource allocation (5-13 bits depending on System BW);        1 bit frequency hopping indicator (as per Rel-8):                    Note that some reinterpretation of the indexing is to be defined so that hopping does not use PRBs outside the configured resource pool for mode 2;                        Only single-cluster resource allocations are valid:                    this implies that if there are gaps in the resource pool in the frequency domain, a resource allocation shall not straddle a gap;                        No RV indicator in SA; and        RV pattern for data:{0, 2, 3, 1}.        
On the other hand, for Mode 2 resource allocation, above steps 1-4 are basically not necessary, and the UE autonomously selects resources for the SA and D2D data transmission from the transmission resource pool(s) configured and provided by the eNB.
FIG. 8 exemplarily illustrates the transmission of the Scheduling Assignment and the D2D data for two UEs, UE-A and UE-B, where the resources for sending the scheduling assignments are periodic, and the resources used for the D2D data transmission are indicated by the corresponding Scheduling Assignment.
FIG. 9 illustrates the D2D communication timing for Mode 2, autonomous scheduling, during one SA/data period, also known as SC period, Sidelink Control period.
FIG. 10 illustrates the D2D communication timing for Mode 1, eNB-scheduled allocation during one SA/data period. A SC period is the time period consisting of transmission of Scheduling Assignments and their corresponding data. As can be seen from FIG. 9, the UE transmits after an SA-offset time, a Scheduling Assignment using the transmission pool resources for scheduling assignments for Mode 2, SA_Mode2_Tx_pool. The 1st transmission of the SA is followed e.g. by three retransmissions of the same SA message. Then, the UE starts the D2D data transmission, i.e. more in particular the T-RPT bitmap/pattern, at some configured offset (Mode2data_offset) after the first subframe of the SA resource pool (given by the SA_offset). One D2D data transmission of a MAC PDU consists of its 1st transmissions and several retransmissions. For the illustration of FIG. 9 (and of FIG. 10) it is assumed that three retransmissions are performed (i.e. 2nd, 3rd, and 4th transmission of the same MAC PDU). The Mode2 T-RPT Bitmap (time resource pattern of transmission (T-RPT)) basically defines the timing of the MAC PDU transmission (1st transmission) and its retransmissions (2nd, 3rd, and 4th transmission).
During one SA/data period, the UE can transmit multiple transport blocks (only one per subframe (TTI), i.e. one after the other), however to only one ProSe destination group. Also the retransmissions of one transport block must be finished before the first transmission of the next transport block starts, i.e. only one HARQ process is used for the transmission of the multiple transport blocks.
As apparent from FIG. 10, for the eNB-scheduled resource allocation mode (Mode 1), the D2D data transmission, i.e. more in particular the T-RPT pattern/bitmap, starts in the next UL subframe after the last SA transmission repetition in the SA resource pool. As explained already for FIG. 9, the Model T-RPT Bitmap (time resource pattern of transmission (T-RPT)) basically defines the timing of the MAC PDU transmission (1st transmission) and its retransmissions (2nd, 3rd, and 4th transmission). ProSe network architecture and ProSe entities
FIG. 11 illustrates a high-level exemplary architecture for a non-roaming case, including different ProSe applications in the respective UEs A and B, as well as a ProSe Application Server and ProSe function in the network. The example architecture of FIG. 11 is taken from 3GPP TS 23.303, “Proximity-based services (ProSe); Stage 2”, v.12.3.0 Section 4.2 titled “Architectural Reference Model”, available at www.3gpp.org, and incorporated herein by reference.
The functional entities are presented and explained in detail in the above cited 3GPP TS 23.303 Section 4.4 titled “Functional Entities” incorporated herein by reference. The ProSe function is the logical function that is used for network-related actions required for ProSe, and plays different roles for each of the features of ProSe. The ProSe function is part of the 3GPP's EPC and provides all relevant network services like authorization, authentication, data handling etc. related to proximity services. For ProSe direct discovery and communication, the UE may obtain a specific ProSe UE identity, other configuration information, as well as authorization from the ProSe function over the PC3 reference point. There can be multiple ProSe functions deployed in the network, although for ease of illustration a single ProSe function is presented. The ProSe function consists of three main sub-functions that perform different roles depending on the ProSe feature: Direct Provision Function (DPF), Direct Discovery Name Management Function, and EPC-level Discovery Function. The DPF is used to provision the UE with necessary parameters in order to use ProSe Direct Discovery and ProSe Direct Communication.
The term “UE” used in said connection refers to a ProSe-enabled UE supporting ProSe functionality, such as:                Exchange of ProSe control information between ProSe-enabled UE and the ProSe Function over PC3 reference point;        Procedures for open ProSe Direct Discovery of other ProSe-enabled UEs over PC5 reference point;        Procedures for one-to-many ProSe Direct Communication over PC5 reference point;        Procedures to act as a ProSe UE-to-Network Relay. The Remote UE communicates with the ProSe UE-to-Network Relay over PC5 reference point.The ProSe UE-to Network Relay uses layer-3 packet forwarding;        Exchange of control information between ProSe UEs over PC5 reference point, e.g. for UE-to-Network Relay detection and ProSe Direct Discovery;        Exchange of ProSe control information between another ProSe-enabled UE and the ProSe Function over PC3 reference point. In the ProSe UE-to-Network Relay case the Remote UE will send this control information over PC5 user plane to be relayed over the LTE-Uu interface towards the ProSe Function; and        Configuration of parameters (e.g. including IP addresses, ProSe Layer-2 Group IDs, Group security material, radio resource parameters). These parameters can be pre-configured in the UE, or, if in coverage, provisioned by signaling over the PC3 reference point to the ProSe Function in the network.        
The ProSe Application Server supports the Storage of EPC ProSe User IDs, and ProSe Function IDs, and the mapping of Application Layer User IDs and EPC ProSe User IDs. The ProSe Application Server (AS) is an entity outside the scope of 3GPP. The ProSe application in the UE communicates with the ProSe AS via the application-layer reference point PC1. The ProSe AS is connected to the 3GPP network via PC2 reference point. UE Coverage states for D2D
As already mentioned before, the resource allocation method for D2D communication depends apart from the RRC state, i.e. RRC_IDLE and RRC — CONNECTED, also on the coverage state of the UE, i.e. in-coverage, out-of-coverage. A UE is considered in-coverage if it has a serving cell (i.e. the UE is RRC_CONNECTED or is camping on a cell in RRC_IDLE).
The two coverage states mentioned so far, i.e. in-coverage (IC) and out-of-coverage (OOC), are further distinguished into sub-states for D2D. FIG. 12 shows the four different states a D2D UE can be associated to, which can be summarized as follows:                State 1: UE1 has uplink and downlink coverage. In this state the network controls each D2D communication session. Furthermore, the network configures whether UE1 should use resource allocation Mode 1 or Mode 2;        State 2: UE2 has downlink but no uplink coverage, i.e. only DL coverage. The network broadcasts a (contention-based) resource pool. In this state the transmitting UE selects the resources used for SA and data from a resource pool configured by the network; resource allocation is only possible according to Mode 2 for D2D communication in such a state;        State 3: Since UE3 has no uplink and downlink coverage, the UE3 is, strictly speaking, already considered as out-of-coverage (OOC). However, UE3 is in the coverage of some UEs which are themselves (e.g. UE1) in the coverage of the cell, i.e. those UEs can be also referred as CP-relay UEs. Therefore, the area of the state-3 UEs in FIG. 12 can be denoted as CP UE-relay coverage area. UEs in this state 3 are also referred to as OOC-state-3 UEs. In this state the UEs receive some cell specific information which is sent by the eNB (SIB) and forwarded by the CP UE-relay UEs in the coverage of the cell via PD2DSCH to the OOC-state-3 UEs. A (contention-based) network-controlled resource pool is signaled by PD2DSCH; and        State 4: UE4 is out of coverage and does not receive PD2DSCH from other UEs which are in the coverage of a cell. In this state, which is also referred to as state-4 OOC, the transmitting UE selects the resources used for the data transmission from a pre-configured pool of resources.        
The reason to distinguish between state-3 OOC and state-4 OOC is mainly to avoid potentially strong interference between D2D transmissions from out-of coverage devices and legacy E-UTRA transmissions. In general D2D-capable UEs will have preconfigured resource pool(s) for transmission of D2D SAs and data for use while out of coverage. If these out-of-coverage UEs transmit on these preconfigured resource pools near cell boundaries, then, interference between the D2D transmissions and in-coverage legacy transmissions could have a negative impact on communications within the cell. If D2D-enabled UEs within coverage forwarded the D2D resource pool configuration to those out-of-coverage devices near the cell boundary, then, the out-of-coverage UEs could restrict their transmissions to the resources specified by the eNode B and therefore minimize interference with legacy transmissions in coverage. Thus, RAN1 introduced a mechanism where in-coverage UEs are forwarding resource pool information and other D2D related configurations to those devices just outside the coverage area (state-3 UEs).
The Physical D2D synchronization channel (PD2DSCH) is used to carry this information about in-coverage D2D resource pools to the UEs in network proximity, so that resource pools within network proximity are aligned. The detailed content of the PD2DSCH is not finalized yet though. LCP procedure for D2D, sidelink, logical channels
The LCP procedure for D2D will be different than the above-presented LCP procedure for “normal” LTE data. The following information is taken from R2-145435, a Change Request 0744 for TS 36.321 in its version 12.3.0 directed at the Introduction of ProSe and its functionality; it is incorporated herewith in its entirety by reference.
The Logical Channel Prioritization procedure is applied when a new transmission is performed.
The UE shall perform the following Logical Channel Prioritization procedure when a new transmission is performed. The UE shall allocate resources to the sidelink logical channels according to the following rules:                the UE should not segment an RLC SDU (or partially transmitted SDU) if the whole SDU (or partially transmitted SDU) fits into the remaining resources;        if the UE segments an RLC SDU from the sidelink logical channel, it shall maximize the size of the segment to fill the grant as much as possible;        the UE should maximize the transmission of data; and        if the UE is given an sidelink grant size that is equal to or larger than 10 bytes while having data available for transmission, the UE shall not transmit only padding.        
NOTE: The rules above imply that the order by which the sidelink logical channels are served is left for UE implementation. Generally, for one PDU, MAC shall consider only logical channels with the same Source Layer-2ID—Destination Layer 2 ID pairs, i.e. for one PDU, the MAC entity in the UE shall consider only logical channels of the same ProSe destination group. Furthermore, in Rel-12 during one SA/data period the D2D transmitting UE can only transmit data to one ProSe destination group.
All D2D (sidelink) logical channels, e.g. STCH, Sidelink Traffic Channel, are allocated to the same logical channel group (LCG) with LCGID set to ‘11’. In Rel-12 there is no prioritization mechanism for D2D (sidelink) logical channels/groups. Essentially, all sidelink logical channels have the same priority from UE point of view, i.e. the order by which the sidelink logical channels are served is left for UE implementation.
Buffer Status Reporting for ProSe
The (D2D) sidelink Buffer Status Reporting procedure is used to provide the serving eNB with information about the amount of sidelink data available for transmission in the sidelink buffers of the UE. RRC controls sidelink BSR reporting by configuring the two timers Periodic-ProseBSR-Timer and RetxProseBSR-Timer. Each sidelink logical channel (STCH) is allocated to an LCG with LCGID set to “11” and belongs to a ProSe Destination group.
A sidelink Buffer Status Report (BSR) shall be triggered if some particular events occurs, as given section 5.14.1.4 of TS 36.321, v.12.5.0. Section 6.1.3.1.a of TS 36.321, v.12.5.0 specifies the ProSe BSR MAC Control Elements and their corresponding content as follows.
The ProSe Buffer Status Report (BSR) MAC control element consists of one group index field, one LCG ID field and one corresponding Buffer Size field per reported D2D destination group. More in detail, for each included ProSe destination group, the following fields are defined:                Group index: The group index field identifies the ProSe destination group. The length of this field is 4 bits. The value is set to the index of the destination identity reported in ProseDestinationInfoList;        LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is being reported. The length of the field is 2 bits and it is set to “11”;        Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a ProSe Destination group after all MAC PDUs for the TTI have been built. The amount of data is indicated in number of bytes; and        R: Reserved bit, set to “0”.FIG. 13 shows the ProSe BSR MAC control element for even N (number of ProSe destination groups), taken from the above cited TS 36.321, v.12.5.0.Mission Critical Push To Talk        
Recently, a service called Mission Critical Push To Talk (MCPTT) service has been studied in 3GPP, which is also captured in 3GPP TS 22.179, v.13.1.0, “Mission Critical Push to Talk (MCPTT) over LTE; Stage 1”, available at www.3gpp.org. A Push To Talk (PTT) service provides an arbitrated method by which two or more users may engage in communication. Users may request permission to transmit (e.g., traditionally by means of a press of a button). The Mission Critical Push To Talk over LTE (MCPTT) service supports an enhanced PTT service, suitable for mission critical scenarios, based upon 3GPP Evolved Packet System (EPS) services. The requirements for MCPTT service defined within can also form the basis for a non-mission critical Push To Talk (PTT) service. The MCPTT Service is intended to support communication between several users (a group call), where each user has the ability to gain access to the permission to talk in an arbitrated manner. However, the MCPTT Service also supports Private Calls between pairs of users. The MCPTT Service builds on the existing 3GPP transport communication mechanisms provided by the EPS architectures to establish, maintain, and terminate the actual communication path(s) among the users.
The MCPTT Service also builds upon service enablers: GCSE_LTE and ProSe. To the extent feasible, it is expected that the end user's experience to be similar regardless if the MCPTT Service is used under coverage of an EPC network or based on ProSe without network coverage. To clarify this intent, the requirements are grouped according to applicability to on-network use, off-network use, or both. The MCPTT Service allows users to request the permission to talk (transmit voice/audio) and provides a deterministic mechanism to arbitrate between requests that are in contention (i.e., Floor control). When multiple requests occur, the determination of which user's request is accepted and which users' requests are rejected or queued is based upon a number of characteristics (including the respective priorities of the users in contention). MCPTT Service provides a means for a user with higher priority (e.g., emergency condition) to override (interrupt) the current talker. MCPTT Service also supports a mechanism to limit the time a user talks (holds the floor) thus permitting users of the same or lower priority a chance to gain the floor.
The MCPTT Service provides the means for a user to monitor activity on a number of separate calls and enables the user to switch focus to a chosen call. An MCPTT Service user may join an already established MCPTT Group call (Late call entry). In addition the MCPTT Service provides the User ID of the current speaker(s) and user's Location determination features. The users of an MCPTT Service may have more stringent expectations of performance than the users of a commercial PTT service.
An MCPTT Service provides Group Call and Private Call capabilities, which have various process flows, states and permissions associated with them. FIG. 14, FIG. 15, and FIG. 16 indicate the high level flows, states and permissions associated with Group Calls and Private Calls. The diagrams apply to the on-network case and off-network case, as from a user perspective the service and concepts should appear similar on the network and off the network. From a technical perspective there might be differences between the on-network states and off-network states (e.g., off the network Affiliation might not require notifying an application server of a user's affiliation and there might also be other differences in the detail depending on the extent to which the off-network capabilities can match the on-network capabilities).
If an MCPTT User wants to communicate with an MCPTT Group they have to be allowed to access the MCPTT Group (i.e., be an MCPTT Group Member), they then have to affiliate and then can have an MCPTT Group as their Selected MCPTT Group. If an MCPTT User is only affiliated to a group this is so that they can receive from the group, however if an MCPTT User has a Selected MCPTT Group this is their group for transmitting on. The differences in states enable an MCPTT User to receive from multiple MCPTT Groups, but specify which MCPTT Group they would like to transmit on.
In particular, FIGS. 14, 15 and 16 show respective MCPTT user state diagrams for a user which has allowed both receiving and transmitting with respect to a particular MCPTT group, a user that is only allowed to transmit and a user that is only allow to receive. In the present state of discussions, this diagram serves merely for illustrative purposes and does not supersede the requirements. It is not exhaustive and does not include all the different scenarios.
It is possible for an MCPTT User to be affiliated with one or more MCPTT Groups. Normally, while in operation, an MCPTT User informs the MCPTT Service about which MCPTT Groups he would like to be affiliated to. These affiliations remain in effect until the MCPTT User removes them, or changes them, or signs out of the service. Some MCPTT Users have permanent affiliations to certain MCPTT Groups and those affiliations are set up implicitly (i.e., automatically) when operating on the network. For those users, the MCPTT Group affiliation starts when the MCPTT Service successfully signs in the user and ends when the MCPTT User's explicit or implicit (e.g., due to inactivity or the turning off of all its devices) request to sign out of the MCPTT Service is acknowledged.
Every time a PTT request is granted a user can start an MCPTT transmission or “talk burst”. An MCPTT Group Call consists of one or more MCPTT transmissions. Whether two consecutive transmissions from same or different users are part of the same call, or the second transmission starts a new call, depends on the configurable maximum length of the inactivity period between the consecutive MCPTT transmissions. This inactivity period can be seen as a Hang Time that starts at the end of the preceding transmission. While this timer is running, the resources associated with the call stay assigned to the call (except in case of pre-emption), which could reduce the latency of future floor requests for this group versus groups who are not involved in a call. When a new transmission starts during the inactivity period, the timer is stopped, reset and restarted again at the end of that transmission.
The MCPTT Service recognizes a number of “special” group calls including: Broadcast Group Call, Emergency Group Call and Imminent Peril group call.
MCPTT Priority Model
Many LTE non-public safety users today subscribe to one particular priority and QoS level of service (e.g., “gold”, “silver” or “bronze”), which always provides fixed differentiation. This model, effective and relatively straightforward for non-public safety users, falls short when it comes to the needs of the public safety applications.
MCPTT Priority and QoS is situational. The MCPTT Service is intended to provide a real-time priority and QoS experience for MCPTT calls, as public safety users have significant dynamic operational conditions that determine their priority. For example, the type of incident a responder is serving or the responder's overall shift role needs to strongly influence a user's ability to obtain resources from the LTE system.
The MCPTT Priority handling for on-network use for MCPTT Calls is conceptually modeled as shown in FIG. 17. The conceptual model identifies three areas of prioritization: prioritization between and within calls, inter-system prioritization, and prioritization at the transport layer (EPS and UE). At the Application Layer a generic, network side, functional entity, “MCPTT Priority and QoS Control”, processes with each request static, preconfigured information about users and groups participating in MCPTT, as well as dynamic (or situational) information about them. Based on the results of this processing, the “MCPTT Priority and QoS Control” provides information to and directs interactions with other functional entities, systems, or layers to ensure, to the extent possible, that from a quality of experience point of view, calls and transmissions are handled properly in accordance to established policy rules.
In FIG. 17, User Static Attributes include information categorizing the user, possibly by several criteria (e.g., first responder, second responder, supervisor, dispatcher, administrator), as well as jurisdictional boundaries and possibly a preconfigured system-wide individual priority level.
The Group Static Attributes include information about the nature/type of the group and the owning organization(s), the jurisdictional boundaries for transmitters and receivers within the group, the normal hours of operation for the group, pre-emption dispositions relative to other groups, and the default minimum priority of the group.
The User Dynamic Attributes include the user/Participant's operational status (e.g., on/off duty), his location, the type of incident (e.g., MCPTT Emergency or Imminent Peril) he might be involved in and whether or not he initiated it, whether or not he is individually involved in a formally managed incident and if yes, the boundaries of the incident area, the incident severity and his assigned role in the resolution of the incident.
The Group Dynamic Attributes include the type of incident (e.g., MCPTT Emergency or Imminent Peril), if any, the group is currently handling and in case of involvement in a formally managed incident the boundaries of the incident area and the incident severity.
As shown in FIG. 18, the higher layers for each particular bearer provide a priority based on the real time attributes (The User Static Attributes, The Group Static Attributes, The User Dynamic Attributes, The Group Dynamic Attributes) a priority value to the MAC layer.
MAC layer may further use this in at least two possible ways:    A) As part of LCP mechanism i.e. together with the Logical Channel and/or destination group priority; and    B) Independently (before/after LCP) to make a go/no-go decision: in this case Logical Channel Prioritization would decide on how much data to which logical channel is allocated (in which group(s)) and then MCPTT priority only reflects in floor arbitration.    At present, the particular procedure for prioritizing logical channels in a UE is not defined.